What I Tested & How I Worked
Platforms & Environments
- Mobile: iOS & Android (React Native builds via BrowserStack and on-device).
- Web: Chrome, Edge, and Safari against Dev, Staging, and Production.
- Unity WebGL: Embedded experiences like the Sagen above.
- Admin Portal: 2.1 front-end portal for organization admins and user provisioning.
Testing Types
- Feature testing for new functionality and UI/UX flows.
- Regression testing from a full test plan I wrote and maintained.
- Exploratory testing to mimic first-time and power users.
- Cross-platform checks to keep behavior consistent across mobile and web.
- Release smoke testing for minor 1.0 releases, 2.0 launch, and early 2.1 work.
Tools & Collaboration
- BrowserStack: device coverage for iOS/Android and browser combinations.
- Monday.com: custom QA board for bugs, polish, and hard-to-reproduce issues.
- GitHub: learned branching and version control practices from the engineering team.
- Miro: used for hackathon planning and feature brainstorming.
- Unity & React Native builds: regularly tested new player and app builds.
Day-to-day I worked closely with Unity, front-end, and back-end developers, plus the Product Manager and Engineering Lead, to make sure issues were understood, prioritized, and fixed.
How My QA Role Grew Over Time
Phase 1 — Exploratory Onboarding (Jul–Oct 2023)
- Came in with zero formal QA experience, so the goal was to use the product like a brand-new user.
- Spent ~90 days inside the app: building Sagans, clicking everything, and reporting anything that felt off.
- Provided UX feedback and surfaced issues that long-time team members had grown blind to.
Phase 2 — Learning QA Fundamentals (Late 2023–Mid 2024)
- Started learning how to properly document issues: repro steps, expected vs actual, environment, and media.
- Inherited an old regression outline and began using it as a base while I learned what good coverage looked like.
- Provided daily testing across features, responded to developer requests, and joined regular stand-ups.
- Met about an hour a month with leads from each engineering team to grow my QA skills.
Phase 3 — 1.0 Hackathon & Rebuild Planning (Oct 2023)
- Participated in a week-long hackathon to evaluate whether to keep Unity and whether our vision was technically possible.
- Did live testing as the team built new prototypes, validating that key interactions actually worked in practice.
- Got hands-on time in Unity and learned how engine changes affected QA and regression risk.
Phase 4 — Building 2.0 & Formalizing QA (Late 2023–May 2024)
- Wrote a fresh regression plan for Sagenverse 2.0 from the ground up as the app was rebuilt.
- Helped shift from one-off DMs and ad-hoc bug reporting into a structured, trackable workflow.
- Verified smaller updates to 1.0 while preparing full coverage for the new 2.0 experience.
Phase 5 — 2.0 Release, 2.1 Work, and QA Maturity (May–Nov 2025)
- Participated in all minor 1.0 releases, the major 2.0 release, and early 2.1 development before lay-offs.
- Owned smoke tests, hotfix verification, and build sign-off checks.
- Expanded use of BrowserStack and improved cross-platform coverage.
- Tested a new front-end portal for organization admins to manage employees and access.
Bug Reporting Workflow & Monday QA Board
From Chaos to a Clean Pipeline
- Originally, bugs were shared through DMs and scattered messages, which made tracking nearly impossible.
- I helped design a dedicated QA board in Monday used by the whole engineering org.
Key Columns & Lists
- Bugs Main intake for issues found during testing and by the team.
- React Front End / Missions Feature-focused slices to keep work organized.
- Polish Improvements that weren’t true defects but would noticeably improve UX.
- Very hard to reproduce Known issues that were rare or environment-sensitive.
- Status Clear states like “New”, “In Progress”, “Ready for QA”, “Verified”.
Each week I met with the Engineering Lead and Product Manager to walk through the board, confirm severity, and make sure the right team (Unity, front-end, back-end) owned each fix.
Example Board View
" alt="Example Monday QA board with lists for bugs, polish, and hard-to-reproduce issues (sensitive details blurred)." />
This is a sanitized example of the QA board I used daily. Sensitive details are intentionally blurred but the structure and workflow are representative.
Key Contributions & Wins
Joined with no formal QA background and became the point person for testing, regression, and release verification. Wrote a full regression plan for Sagenverse 2.0 and helped establish a repeatable QA process.
Found edge cases and UX issues that would have shipped without a dedicated tester. Engineers appreciated my friendly communication style and thorough eye for “little things” that make a big difference in the final experience.
Helped move the team away from ad-hoc DMs to a structured, visible workflow, with weekly triage meetings that aligned Product and Engineering on priorities.
What I Learned as a Sole QA Tester
- Good QA is as much about clear communication as it is about finding bugs.
- Exploratory testing early on surfaces issues before they’re baked into the product.
- Detailed repro steps and environment info save developers time and reduce back-and-forth.
- Cross-platform apps require a healthy respect for differences between browsers, devices, and OS versions.
- Being friendly, curious, and collaborative makes it easier to ask hard questions about quality.
Want to know more?
I’m happy to walk through the Sagen at the top of the page, discuss my regression plans, or talk about how I’d approach QA at your company.
If you would like yo know how Sagenverse can help your organization with digital story telling go to their website at sagenverse.com.